In recent years, the world has witnessed explosive growth in the demand for wireless communications and it is predicted that this demand will increase in the future. There are already over 500 million users subscribing to cellular telephone services and the number is continually increasing. Eventually, in the not too distant future, the number of cellular subscribers will exceed the number of fixed line telephone installations.
Other related wireless technologies have experienced growth similar to that of cellular. For example, cordless telephony, two way radio trunking systems, paging (one way and two way), messaging, wireless local area networks (WLANs) and wireless local loops (WLLs).
A new type of wireless service, digital satellite ratio is expected to begin service in the near future. In this type of paid subscription service, the programming contents of dozens or hundreds of stations are broadcast via satellite to fixed or mobile radio receiver platforms. It is predicted that there will eventually be tens or possibly hundreds of millions of radio platforms capable of receiving such types of broadcast signals.
One component all these types of wireless communication devices (i.e. receivers, transceivers, etc.) have in common is the processing device. Cellular transceivers, satellite radios, etc. all have some form of data or signal processing components that utilize firmware or software in their operation. Subsequent to the manufacturing of these devices, it may often be required to upgrade them with new versions of firmware or software. Typically it is not possible to upgrade the firmware in thousands or millions of devices once they are distributed in the field.
A diagram illustrating the internal architecture of a general purpose processing device is shown in FIG. 1. The device, generally referenced 10, comprises program memory, data memory, a processing core and other peripherals such as communication ports. Often, the processing device is optimized for certain applications or tasks. For example, the device may be optimized for signal processing tasks. In this case, the device 10 comprises program read only memory (ROM) 20, patch random access memory (RAM) 22, data ROM 12, data RAM 14 and a processing core 16 optimized to perform digital signal processing (DSP) operations. The device also comprises one or more interfaces including communication ports 19 and a host interface 18.
The host device 24 communicates with the DSP device via host interface 18. The host may comprise a personal computer (PC), microprocessor, microcomputer or any other computing platform that functions as a host to the DSP device 10. Typically, the host 24 comprises program memory, data memory and some form of nonvolatile memory 26 such as EEPROM, EEPROM, Flash, etc.
In a typical arrangement, the host performs more general tasks such as providing the user interface, running a real time operating system, managing tasks, memory, I/O, etc. More sophisticated signal processing functions are handled by a processor more optimized for handling signal processing tasks, such as DSP device 10.
Program code for such a DSP device is developed and burned into the device during manufacturing of the Integrated Circuit (IC). The program is thus ROMed once it is finalized. As happens often in complex processor designs running large sophisticated programs, one or more bugs are discovered after the device is manufactured and distributed in a product. In order to fix the one or more bugs, the program code must be modified. This requires that a portion of the program code ROM 20 must be updated. The updates may comprise removing, adding or changing program code.
In such cases, a technique, well known in the art, is used whereby the modifications to the program are stored in nonvolatile memory 26 in the host. The patch RAM 22 is loaded from the host memory via the host interface every time the device is reset. The DSP or other processing device is constructed such that the patch RMA is within the program code (i.e. program RAM 20) address space. The format of the patch RAM typically comprises a plurality of patches wherein each patch includes a start address and end address followed by the data to be inserted between the start and end address. Thus, the processor knows where to insert the patch and knows the length of the patch.
At the start of operation of the processor, the program counter begins counting. When the program counter reaches an address that matches a start address in the patch RAM, an internal trap is generated and the processor reads and executes the program as contained in the patch RAM rather than the program ROM 20.
Thus, in this manner, the patch RAM mechanism can be used (1) to correct errors after a program ROM or processor containing an internal program ROM is released and (2) to permit the development of the device or product to continue whereby the differences between software revisions, including changes and bug fixes, can be installed in existing products by placing the differences in patch memory.
A problem arises, however, when the program code needs to be updated and is stored in nonvolatile memory and incorporated in products that are in consumer's hands dispersed over a large geographic area. In this case, remote downloading is logistically difficult and by nature insecure. Many consumer products are generally packaged in a ‘closed’ manner without any easy access to any data ports. Once a device or product is in the field in consumer's hands, it is difficult to perform program updates. In such cases, users must return products to a central facility to perform the update. Imposing this requirement on consumers is very burdensome and is likely to be met with resistance and reluctance in the marketplace, and in addition is most likely to be very costly to the manufacture and/or distributor.
One solution to this problem is to distribute the patch program over a network that is accessible to consumers and the product, such as the Internet. Another solution is to distribute the patch over a wireless network if the product comprises some form of wireless communications such as a radio. In this case, messages, containing patch programs can be distributed periodically to each device over the wireless channel, e.g., cellular, satellite, etc.
Given such a download network, a mechanism is required for determining when the download is complete and whether the data received is correct. A length field included in the header information can be used to indicate when a download is complete. Further, a cyclic redundancy code (CRC) checksum is typically used to detect whether a download was received correctly.
Further, it is also desirable to know whether the download was received from the intended source. The device should have a mechanism of detecting if the download was legitimately transmitted from a known source or was injected by a hacker for purposes of compromising the system. In addition, it is desirable to store the downloaded patch program securely in memory so as to prevent tampering of the stored memory contents by hackers.
A disadvantage of the patch program distribution scheme described above, however, is that it is vulnerable to attack by hackers. This is especially the case when the processing device to be patched is a radio wherein the patch program is distributed over a satellite or terrestrial wireless network. For example, in a radio network that operates on a pad subscription basis, the activation and deactivation of radios is performed over the air. A hacker could access the patch contents and modify it in numerous ways, such as simulating a message to enable service on a particular radio for an indefinite period of time, enabling the reception of any number of premium channels, etc.
In the case where the programming content of the radio service is transmitted in an encrypted fashion, transmission of a cleartext version of the patch program potentially can enable a hacker to modify the program code so that it outputs the encryption keys stored in the device via a communications port, e.g., RS-232, etc. The encryption keys are normally used by the device to decrypt data received over the channel.
A hacker that gains access to the processor device via the patch program can (1) potentially gain knowledge of any encryption keys used, thus compromising the security of the radio system; (2) change the program to keep the radio in a state of perpetual activation/authorization, i.e. the radio can be programmed to ignore deactivation/deauthorization messages or to keep premium stations always authorized; and (3) utilize the ability to change the program contents to learn about the internal software algorithms, reverse engineer them and sell the algorithms to others to enable service.
Thus, there is need for a system for distributing program patch updates that is not vulnerable to attack by hackers and that does not lead to the security of the system being compromised.